干货 | 高频多因子存储的最佳实践

量化投资与机器学习微信公众号，是业内垂直于量化投资、对冲基金、Fintech、人工智能、大数据等领域的主流自媒体。公众号拥有来自公募、私募、券商、期货、银行、保险、高校等行业30W+关注者，荣获2021年度AMMA优秀品牌力、优秀洞察力大奖，连续2年被腾讯云+社区评选为“年度最佳作者”。

因子挖掘是量化交易的基础。随着历史交易数据日益增多，交易市场量化竞赛的不断升级和进化，量化投研团队开始面对数据频率高、因子数量多的场景，以10分钟线10000个因子5000个股票为例，一年的因子数据约为 2.3T 左右，1分钟线的数据量达到23T，3秒线的数据量将达到460T。如此量级的数据就对因子存储方案提出了很高的要求。

高频多因子存储有哪些挑战？

在数据高频次和因子高数量的双重叠加之下，会很容易将数据量推到 T 级，那么高频多因子的存储方案就必须同时面对以下问题：

庞大的数据量

因子计算通常有3个维度，股票、因子和时间。我们做一个简单的计算，国内股票总个数按5000来算；因子个数一般机构大约为1000起，多的甚至有10000；时间频率最高的是每3秒钟生成一次数据，频率低的也有10分钟一次——也就是说，一只股票一个因子一天会生成24到4800条 tick 数据。面对如此庞大的数据量，如何保证高效的数据写入是因子库存储的一大挑战，如果不能支持并充分发挥多块磁盘的 IO，写入耗时将达数小时以上。

最适合金融计算的输出方式

金融行业的数据分析通常需要以面板模式进行。对于读取随机标的（A股市场目前约5000 股票）、随机多个因子（10000个因子中随机取1000个因子）的场景，要能从海量的因子数据中尽可能高速并精准读取数据，减少无效 IO ，并以需要的方式（通常是因子面板模式）将数据读取出来，这对数据库的性能提出了高要求。

灵活变化的因子库

因子库经常会发生变化，往往需要新增因子、修改因子定义，或加入新的股票等。面对 T 级的因子数据，单个因子的新增、修改、删除耗时应该保证在秒级才能确保整体量化投研的效率。

对于以上的每个问题，高频多因子的存储方案除了尽可能每一方面都有良好的表现，更重要的是不能有明显短板，否则在数据操作量级大幅上升后，会大幅度降低因子量化的生产效率。总体来看，高频多因子场景对解决方案提出了以下几点要求：

• 保证写入高效性；
• 支持高效、灵活的读取方式，且以最适合金融计算的方式输出；
• 支持高效的因子库运维（新增因子及因子数据的修改、删除）。

为了使广大用户更方便地实现因子计算和管理，助力更高效的投研和生产，DolphinDB 结合多年服务金融量化机构的经验，已经实现了部分国内常用因子库，并且支持研究和生产一体化。

下文中，将基于高频多因子存储场景，为大家介绍一个基于 DolphinDB 实现的因子库和因子存储方案，对比不同存储模式下的性能。

这里也给大家推荐一下，12月1日（周四）晚7点半，DolphinDB CEO 周小华博士和 DolphinDB 数据分析负责人毛忻玥将在线上开讲，围绕因子库性能对比、高频多因子存储解决方案的优劣势分析展开讨论，并结合实际案例展示高频多因子存储的最佳实践。干货满满！快来报名吧~

长按下方海报识别二维码即可报名参与活

国泰君安 191 Alpha 因子库

国泰君安 191 Alpha 因子库来源于国泰君安2017年6月份公布的研报《基于短周期价量特征的多因子选股体系——数量化专题之九十三》，属于短周期价量因子。为了方便用户计算因子，DolphinDB 实现了所有 191 个因子的函数，并封装在模块 gtja191Alpha 中。

除此之外，DolphinDB 还为大家实现了其他市面常用的因子库，包括 WorldQuant 101 Alpha、TA-Lib、MyTT 等，用户可以直接调用模块，实现因子高效计算。

10分钟级10000个因子存储方案对比

本案例使用9块HDD硬盘进行测试。

因子数据在实际存储时通常会有宽表和单值模型两种选择。

宽表模式数据如下表所示，宽表模式的面板数据通常是计算所需要的，这个模式存储的数据，可以直接供给量化程序计算，但是宽表模式的数据存储在因子新增和因子数据修改场景会耗时比较高。

单值模型一般有4列：时间戳、股票代码、因子编号以及因子值，如下图所示；单值模型的数据在需要面板数据的场景，需要将数据转换成面板模式。

针对以上两种模式的存储，我们设计以下两种存储方案，两种方式均采用 TSDB 引擎进行存储：

方案1-单值模式

按 月 Value 分区 + 因子名 Value 分区 , SortColumn: SecurityID + TradeTime

方案2-宽表模式

按 月 Value 分区 + 股票 Value 分区 , SortColumn: SecurityID + TradeTime

这里我们进行一个月的因子数据的写入、查询、修改、删除来比较这两种高频因子存储模式。

因子写入

宽表模式在数据写入速度上优于单值模式，存储空间上略优于单值模式。需要注意的是，由于此处因子值用的是随机浮点数，几乎没有重复，所以压缩比很低。

因子查询

查询 21 天全市场 5000 只标的的 1000 个因子数据，窄表的查询会将数据转换成与宽表一样的面板数据输出。在机械硬盘情况下宽表模式对一万个因子随机查询1000个因子的初次查询速度慢一些；查询前1000个因子则速度较快。即使比对宽表模式最快情况，窄表模式下经过pivot by转为面板数据后的查询速度也更快一些。

数据运维

因子数据的运维包括新增因子、更新因子、删除因子。

1、新增因子：在新增因子的场景，窄表模式只需要进行 Insert 操作，将新增因子数据写入；而宽表模式需要先进行addColumn 操作，然后更新新增因子列数据，DolphinDB 目前的更新机制是重写。而宽表模式在当前设计下，如果要更新一列因子数据，需要把所有的分区数据全部重写，所以耗时非常长。

2、更新因子：量化投研中，重新计算因子数据是常见的场景。根据窄表模式下的分区规则，对指定因子数据更新时，可以精确定位到因子所在分区，并进行修改，所以耗时在秒级；而宽表模式的更新方式如上节所述原因，耗时非常长。

3、删除因子：删除因子虽然不是必须的，但可以释放存储空间，以及提供其他便利。当前窄表模型的分区方案在删除指定因子时耗时在秒级 , TSDB 引擎下的宽表模式目前不支持删除因子列。

通过一个月的数据对比，我们发现：

• 十分钟级一万个因子数据场景下，宽表模式的因子写入速度高于单值模型。
• 因子数据查询方面，单值模式优于宽表模式。
• 因子数据运维方面（包含新增因子、更新和删除因子），单值模式的效率远远优于宽表模式。

综合考虑，在高频多因子的场景下，合理设计存储方案的单值模式是最好的解决方案。

直播中，我们将进一步为大家介绍更丰富的因子库，并使用更贴近实际用户生产环境的硬件配置和数据量来进行测试，以提供可以参考的性能基准。

长按识别二维码，或点击阅读原文，均可报名参与活动！